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How to contact IBM’s APPC Market Enablement Group 


What is APPC Market Enablement? 
APPC Market Enablement is a new department within the Architecture and Tele- 
communications group of the Networking Systems division. Our mission: to 
provide you with the information and support you need to market and use APPC, 
APPN, and CPI-C successfully. We provide a wide vanety of different services to 
help you get the most from promoting and using APPC. 


Publications and Forums: To spread the good news about APPC, we use a 
vanety of media: 


¢ Our articles appear regularly in IBM journals. We encourage the publication of 
features and updates on APPC im the trade press as well. 


¢ We produce and distnbute a comprehensive catalog of APPC development tools 
offered by IBM and other vendors. 


¢ We also provide information on APPC through internal and external forums: 
— CompuServe 


— IBM Information Network 


Consulting: Our team members have the skills and expertise to answer your 
questions and concerns about APPC, APPN, and CPI-C. We regularly provide 
consulting services on APPC to IBM marketing representatives and developers. We 
provide sumuar services directly to customers by special arrangement only. 


How Can We Help You? | 


Please contact us and Iet us know how we can help you. 


IBM APPC Harket Enablement 

P.0. Box 12195 

Department E42, Building 673 

Research Triangle Park, North Carolina USA 27709 


IBM VNET: APPCHRKT at RALVH6 
Internet: appcmrktGralvm6.vnet.ibm.com 


CompuServe: GO APPC 


Fax: 919-254-6050 
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Why you should read this tutorial 


This tutonal is for network administrators who want better performance from their 
SNA networks and want to know what can be done to improve it. Admunistrators 
will need to read this document if: | 


¢ They want to know the latest tuning techniques available for APPC(LU6.2). 


¢ They know there is more horsepower in their network(s) and want to leverage 
that power for their users. 


¢ They have never before considered tuning APPC data transport for higher 
throughput. 7 
Consider these benefits: 


1. You will have a good foundation in what makes SNA networks perform well or 
poorly. 


2. You will be able to tune your network equipment to give vour users better bulk 
data performance. A brief description of the improvements I made follows. As 
vou can see, tuning really pays off. 
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Onginal Throughput 


Tuned Through put 


Turbo Adare cwy2 


Busmaster Adapter 


Figure 1. Affects of tuning a PC network 
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Workstation to Host Communication 


Untuned throughput 


Tuned throughput 


Communications Manager 


Figure 2. Affects of tuning a Host and PC network 
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Of course, network administrators are those who have the privilege to change 
network parameters. If network tuning ts something you are not authorized to do, 
vou should pass this good information along to somcone who is authorized to make 
the changes I recommend. 
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- Disclaimer 


Since your data transfer applications and network will likely be different from the 
test networks I used to investigate performance, your results will not be the same as 
mine. These results are a subset of the whole performance picture, and it is impor- 
tant to note that the conclusions are based only on single data session throughput. 
The recommendations, therefore, may exceed what you can configure if your 
machine has to support many sessions/links/users concurrently. Some of the values 
you use may have to be less than what I recommend because of trade-offs between 


memory/hardware and the number of sessions, links, and conversations your machine 


needs to support. 


Further perspective on what the numbers reported here mean to you is in 
*Niethodology” on page 45. 


Disclaimer 
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Why is tuning necessary? 


Simply stated, tuning is setting the parameters of the network software to best 
match and utilize physical resources. As physical and logical characteristics of net- 
works change, so must the parameters that allow for efficient use of both. Tuning 
your network allows you to maximize your investment in SNA network software 
and hardware. 


SNA has a history of change 
: SNA products have evolved for over twenty five years, and so have the networks 
which are built around them. This evolution comes from new applications, putting 
new demands on the network, new hardware expanding capacity, and new system 
software umplementing advanced architectures. | 


As these networks and products have evolved, there have invariably been compro- 
mises: New network products must interoperate with older versions of many other 
products, but must also provide enhanced function and greater capacity. Users also 
had to make migration choices: network managers had to enable new high demand 
applications while maintaining response times for existing users and applications. 


In response to all of these forces. SNA architecture developed a plethora of options 
to allow interoperability and evolution. Network parameters chosen for a new set 
of applications or users must be evaluated before new users are added to a network 
domain. In addition, the continuing increase of end user software and hardware 
capacity means that existing network connections and pathways must be evaluated 
for efficiency on a continuing basis. 


The outcome of all of these forces is networks where tuning and planning are neces- 
sary. 
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How this tutorial is organized 


“Basic concepts” on page 13 will explain basic terms and concepts used later in the 
paper. | 


Then, there are three main sections to this paper: 


1. The first is “General Tuning Guidelines” on page 17. It covers some general 
rules and guidelines to follow when tuning any SNA network. 


2. “Platform Specific Recommendations” on page 27 covers how to tune the pro- 
ducts I tested. 


3. In Appendix A, “Test lab results - microcomputer and mainframe network” on 
page 45 and Appendix B, ““APPC Optimal Performance Configuration on 
OS 2 and DOS”” on page 55, you'll find the detailed results of the tuning 
studies this paper 1s based on. Those tests were conducted at IBM labs in 
Research Tnangle Park, NC. In that section, youll find: 


a. The data transfer response times both before and after tuning. 
b. The parameter settings in the products both before and after tuning. 


c. Details of the networks. Use this section to help determine whether or not 
your tuning activities have fully realized your equipment’s capabilities. If 
you have similar equipment to these networks, and vour data throughput is 
orders of magnitude less than what I achieved, there 1s still a bottleneck 
somewhere in your network. More tuning, possibly not related to your 
network, should be done. 


The data presented in Appendix A, “Test lab results - microcomputer and 
mainframe network” on page 45 was from tuning end station SNA 
products(NS:DOS, Communications Manager, and SNA Services.'6000) communi- 
cating with a host(VTAM 4.1 for MVS). 


The test results presented in Appendix B, ““APPC Optimal Performance Config- 
uration on OS’2 and DOS” on page 55 were onginally reported in “APPC 
Optimal Performance Configuration for OS’2 and DOS” by Jill Bodine (called “the 
old report” hereafter). The old report is superseded by this report because of its 
inclusion here. 
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General Tuning guidelines section 
The topics in this section apply to all SNA networks, due to the nature of the SNA 
network protocol. 


Each topic is preceded by a 


Recommendation 


Which may be followed by an... 


Exception 


to the rule. 


Platform Specific Recommendations section 


These topics cover actual SNA software settings in real products. Parameter settings 
I recommend wil appear as 


In some instances, I reeommend performing small experrments with performance 
and changing product parameters. Always use tools available with the products to 
ensure that the parameters are changing as desired. Protocol negotiations with other 
computers can result in network parameters less than what vou have configured. 
This downward negotiation can lead to poor performance. 


There is a very useful (and free!) tool offered by IBM's APPC Market Enablement 
Team which can be used to quantify performance gains in SNA networks. Itis | 
called APING. It 1s an APPC version of the popular SOCKETS PING tool. I 
suggest you install APING on all of your machines running SNA protocols. It will 
then be very easy to tell if and how much your tuning 1s affecting response time. 


12 Getting the most from APPC: A network tuning guide 


APPC Market Enablement 


Terms 


Basic concepts 


Here are some terms you will see in this paper. 


Acknowledgement 
A message sent from one machine to another confirming receipt of data. 
API 


Application Programming Interface. A set of commands geared to perform a 
specialized set of tasks. Examples are APPC, CPIC, SOCKETS, and 
PostScnpt. This paper deals mainly with APPC(also known as LU6.2). 


SNA | 

Systems Network Architecture. A network protocol used to transfer data from 
one computer to another. 

Window 


A quantity, or count, of data frames which machines remember they have sent. 
Each window of data transmitted requires an acknowledgement to be sent in © 
retum. 


Pacing 


‘A mechanism used to control the flow of data in SNA. Pacing allows large, fast 


machines to seamlessly operate with smaller, less capable, machines. Pacing is 
unidirectional. That means that a machine can have a different send window 
than its receive window. 


Data Link Control (DLC) 


The communications link protocol used to transmit data between two physically 
linked machines. 


Request /Response Unit (RU) 

A unit of SNA data which carnes user and network control data. They are used 
to carry user application data from one machine to another and can vary greatly 
in size. 

Path Information Unit (PIU) 

An RU or RU segment with SNA routing information added. 


Conwinner 


Contention winner. A session for which an LU has won the nght to speak first 
on any conversation mapped over It. 


Conloser 


Contention loser. A session for which an LU lost the nght to speak first on any 
conversation mapped over it. The LU is second to speak on these sessions. 


Negotiation 
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A process used by two machines establishing a links sessions and conversations. 
Values like RU sizes, DLC frame sizes, pacing windows, etc. are decided upon 
during negotiation. 
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Concept: Data with DLC and SNA headers 


The following figure illustrates the various routing information added to user data 
(RUs) for transmission. | 


DLC Frame 


PIU 
DLC ! LAN 
Lan Header te is | User Data Tailor 


SNA Request Unit: Contains user data 


SN.4 Resource Header: contains SNA routing information 


SN.4 Transmission Header: contains SN.A and link routing information 


Figure 3. Data with DLC and SNA headers 


Basic concepts 
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General Tuning Guidelines 


SNA Guidelines 


Regardless of the platform, any SNA implementation will respond favorably to the 
tuning guidelines suggested in this section. Some vanations in how SNA products 
are implemented will lead to some vanation, though. You may have to make 
exceptions to these guidelines. 


Use APPC(LU6.2): the most advanced SNA LU 


Recommendation 


Look for bulk data transfer applications in your network not written to the 


APPC API and cither migrate them to APPC or replace them with APPC based 
data transfer applications. Plan to write all new applications using APPC. 


Recommending you use LU 6.2 in this tutonal may seem like stating the obvious, 
but differences exist between LU6.2 and older LU types that bear mentioning. 


Early LUs, (e.g.LU0, LU2, LU3) are clearly dated technology. Of these, LU2 is the 
one most often misused for data transfer. This LU protocol is suited to old termi- 
nals which had limited ability to run their own communications protocols. LU2 
devices can only send 32K bytes of data at a time, and must simulate an ENTER 
key to acknowledge EVERY record the client sends. These charactenstics, as well 
as the high amount of control overhead needed to implement 3270 data stream, 
limit LU2’s ability to move large amounts of data efficiently. 


APPC(LU6.2) has features like a large send/receive record size (the architecture 
allows up to 2 gigabytes to be sent or received at a time, and some products allow 
up to 64 kbytes) and enhanced data buffering which enable it to move data very 
efficiently; and, once a LU6.2 conversation has been established, the size of the 
control overhead relative to the data being transported becomes very small. 


There are several documents available to help with migration from LU2 to LU6.2. 
Contact IBM’s APPC Market Enablement group to obtain any of the following: 
1. APPC Design for HLLAPI and 3270 Programmers 
2. HLLAPI or APPC: Design Cntena 
3. CICS 3270 to APPC Chent;Server: A Migration Methodology 


Use modes wisely 
Recommendation 


For bulk data transfer applications, use a mode which has large RU and pacing 
window values, and uses a class of service which has a MEDIUM or LOW trans- 
mission priority. The architected mode #BATCH is a good mode to use for bulk 
data transfer. | 
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SNA gives users many options to customize the characteristics of individual data 
sessions. These characteristics (like RU sizes, pacing window values, transmission 
pnonty. and security requirements) are held in profiles called MODES. It is impor- 
tant to use a mode that best balances the needs of an application to do its job with 
the needs of all users in the network. In this way, no “greedy” applications can 
dominate the use of network resources while other applications are locked out. 

Bulk data transfer requires modes with large RUs and pacing window sizes, and a 
secondary (not highest) transmission priority. 


Request Units(RUs) 


Recommendation 


Specify an RU as large as possible for the modc your file transfer application 
uses. Then, using available system management tools, ensure that the RU size 
negotiated matches what you configured (see the individual product sections in 
“Platform Specific Recommendations” on page 27 for those tools). 


IN ADDITION, BE SURE THE RU SIZE YOU CONFIGURE IS AN INTEGER MULTIPLE 
OF THE DLC FRAME SIZE. THIS WILL HELP YOU AVOID SENDING SMALL DLC 
FRAMES. SENDING SMALL DLC FRAMES IS DETRIMENTAL TO LINK 
THROUGHPUT. 


¢ Ifyou plan to configure an RU which is close in size to your DLC frame size, 
be careful that an entire RU can fit into a DLC frame. This requires that 
the length of the DLC header be subtracted from the overall DLC frame size 
to determine an appropriate RU size. Some platforms have configuration 
options that automatically do this calculation for you. Examples include: 


— DEFAULT RU SIZE in Communications Manager]2 
— * for the RU size in NS/DOS’s MODE.NSD file 


— *CALC for the RU in the Mode Definition (\LODD) statement in 
AS/400s. 


° Ifyou make your RU size larger than the DLC frame size, select an RU size 
that is as close as possible to an even multiple of the DLC frame size. There 
can be up to 9 bytes of SNA header information attached to an RU in APPN 
networks, and up to 29 bytes in Subarea networks: 


— For Subarea networks, make your RU size an even multiple of (the DLC 
frame size - 29) 


— For APPN networks, make your RU size an even multiple of (the DLC 
frame size - 9). 


Exception 


The AS/400 calculates the most efficient RU size for the user. See “AS/400 


tuning recommendations” on page 34 for AS/400 tuning recommendations. 


A RU 1s the construct in SNA that carnes user application data through the 
network. Its size can be uniquely configured for each MIODE you have configured. 


SNA products generally ship with default mode tables specifving RUs less that 2k 


bytes. This suits interactive traffic and users with small data transfer requirements. 
But, for bulk data transfers, paving attention to RU size is very important. A size 
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of 4k bytes is good, and in terms of single session throughput, going all of the way 
to a 64k byte RU will theoretically provide a gain in performance. 


Trade offs 
Increasing the size of RUs that a machine sends and receives increases the amount 
of memory needed to store those RUs. This affects a data receiver more than a data 
sender. A data receiver must have enough memory available to receive a whole 
window of RUs: (RU size) x (window size) bytes while data senders only need one 
RU buffer. | 


Segmenting RUs: Segmenting occurs when an entire RU cannot fit into a DLC 
frame for transmission. The RU 1s broken into segments small enough to fit the 


DLC frame size. It is then up to the data receiver to reassemble. Example: 


An RU segmented into two DLC frames 


DLC Frame 


PIU 


ieiteadion FUE N ae Re 
Header 


LAN 
Rl Traiier 


First part of RU 


DLC Frame 


Lae 
DLC ; 


Remainder of RU 


Figure 4. An RU segmented into two DLC frames 
Segmenting should be utilized to its fullest capability with one caveat: ensure that all 


other tuning has been done before employing segmentation. It 1s best to increase 
the DLC frame size and pacing windows(DLC and RL) first. 
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Pacing windows 
Recommendation 


If your SNA product supports adaptive pacing, use the maximum allowable RU 
pacing window. Also insure that during bulk data transfers, the window is 
increasing to at least 8. See Appendix C, “Determining pacing window sizes” on 
page 63 for product specific help with this task. If the window is not opening up 
to 8, there is a resource constraint or configuration problem along the data path 
that must be addressed. 


If your SNA product only supports fixed pacing use a window size of 8. Then, 
increase the window size and note any performance change. If there is no increase 
in performance, return the value to 8. 


Letting your computer sit idle 1s a waste of resources. Without an adequate pacing 
window configured for your APPC sessions, both the client and server will wait for 
data acknowledgements to travel through the network. Large pacing windows help 
eliminate send wait behavior in data transfers. Data traveling from one machine to 
another can be sent continually while that machine receives acknowledgements, thus 
using network capacity very effectively. 


There are two pacing techniques in SNA: fixed and adaptive pacing. Fixed pacing 
was the orginal pacing scheme used in SNA. Adaptive pacing 1s a more advanced 
scheme. Products that support adaptive pacing can perform fixed pacing when 
communicating with a machine that only supports fixed pacing. The decision on 
the type of pacing used on sessions is automatically negotiated between two 
machines: the user does not have to configure the type of pacing two machines will 
use. 


Fixed pacing: If the two communicating machines use fixed pacing. ensure a large 
pacing value is configured. This may require a little planning for memory consump- 
tion based on the buffers needed to support the window. 


A word of caution about fixed pacing and memory consumption: Pacing helps per- 
formance to a point, but has negligible effect when increased beyond that point. 
Since every network behaves differently, some experimentation will be required to 
determine at what value to stop increasing the window size. It 1s important not to 
specify a value that is any larger than necessary, as some buffers set aside for pacing 
will never be used. 


Adaptive pacing: Adaptive pacing algonthms use memory availability to determine 
the best window size. Memory availability in the receiving machine will limit the 
size of the pacing window. Therefore, it is very efficient, since adaptive pacing algo- 
rithms are designed to use only what memory 1s available at the tume of data 
transfer. If littke memory is available due to some other system activity at that time, 
few buffers will be available. If many buffers are free, they will be used to increase 
throughput. 


In short, adaptive pacing will never squander storage because the window size 
changes exactly as the amount of available memory changes. For machines using 
adaptive pacing, ensure the configuration allows for enough buffer space for a 
window of 8 RUs bytes or more. This may require looking at buffer availability 
Statistics if memory shortage 1s suspected in slowing down adaptive pacing. 
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It is also umportant with adaptive pacing to realize that physical memory and avail- 
able buffer constraints along the path between communicating LUs affect the size 
that the adaptive pacing window can be increased to. 


Send and receive pacing: Both of the above pacing techniques allow for different 
size windows based on the direction of data flow. So, while a machine may be able 


to send 8 frames before requiring an acknowledgement, its partner may require an 


acknowledgement for each frame it sends. So when increasing pacing window sizes, 
be sure that both send and receive windows are increased. This will ensure con-— 
sistent response times for sending and receiving data. 


Example 


- Machined uses fixed pacing, and 1s using a send window of 8 and a receive 
window of 63: 


¢ When machined 1s sending data. the send pacing window(8) governs 
number of RUs it can SEND before receiving a message saying it’s OK to 
send more. MachineA can only send 8 RUs before it must receive an 
acknowledgement. If this acknowledgement is not received by machineA 
before the 8th RU is sent, it must stop sending data and wait for an 
acknowledgement. | 


¢ When machineA 1s receiving data, its RECEIVE pacing window governs 
how many RUs it can receive. The sending machine will only send 63 RUs 
unless MachineA sends a message stating it can receive more. It will send 
an acknowledgement for every 63rd RU received. 


Mode Consistency and Propagation 


Consistency 


Recommendation 


Determine what modes your data transfer applications use. Then, make sure 


those modes are consistently defined and propagated across your entire network. 


SNA modes are profiles which determine the charactenstics of sessions. For 
example: the architected mode #BATCH 1s generally defined to have a large RU 
size. large pacing windows, and a medium to low data transmission pnonty. When 
a session is established as a #BATCH session, the session takes on those character- 
istics Of the #BATCH profile. 


To get consistent response times from your SNA network, session characteristics 
must be consistent throughout your network. They way you can achieve consist- 
ency is by paving close attention to the modes your applications use: make them 
consistent and ensure they are defined everywhere(propagated) in your network. 


The easiest way to ensure consistency in modes is to make your applications use 
one of five architected user modes on their ALLOCATE command: 


¢ The “BLANK” mode 
° #BATCH 
¢ =BATCHSC 


General Tuning Guidelines 21 


APPC Miarket Enabternent 


e INTER 
© Z4INTERSC 


These modes ship with many SNA products so using them is an easy way to gain 
consistency. 


If your applications use a specialized mode, be sure the mode 1s defined consistently 
in vour network. 


Propagation 
After ensuring a mode’s consistency, you must thoroughly propagate the definition 
in your network. This means you must define the mode in all of the products that 
will be communicating using the mode. 


The cost of inconsistency 
With a mix of LUs shanng the same modes, it is not always obvious where the 
mode definition governing session setup will be taken from. In some cases, it 1s 
taken from the definition for the bind initiating LU (the Initiator). and in other 
cases taken from the definition for the receiver of a bind (the Receiver). So a bind 
sent from B to A might have differing characteristics from one sent from A to B. 


The following example is a result of mode inconsistency and propagation. These 
circumstances would lead to a widely varving response time trom the same apphica- 
tion doing the same operation. This tends to make users upset. 


Example 


1. A PC running Communications Manager’2 (CM _ 2) 1s configured so the 
mode, #BATCH, 1s to have a session limit of 4, and the minumum number 
contention winner sessions 1s set to 2. 


2. CICS’s session definition for the CM 2 station specifies 
AUTOCONNECT(ALL). 
3. The parameters in CICS. VTAM. NCP and CM 2 are such that if CICS 1s 


the Initiator in a session with mode #BATCH, the RU size is negotiated to 
256 bytes and if CICS is the Receiver, the RU 1s 8192 bytes. 


4. When the first(SNASVCMG) session 1s established between CM 2 and 
CICS, all sessions are bound. This leaves CM 2 with two Conwinner 
sessions(sessions 1 and 2) and two Conloser sessions(sessions 3 and 4). 


5. A little later on. both sessions which have 8192 byte RUs are in use when a 
file transfer application starts a conversation from CM. 2 to CICS. 


6. Since two sessions are available, the session chosen will be one with a 256 
byte RU, and the file transfer happens at a snail’s pace. 


7. Later on, all sessions are free, and the file transfer application allocates a 
— conversation to CICS. 


8. Since a Conwinner session 1s free. it 1s selected. Since the RU size for this 
session 18 8196 bytes. the file transfer completes much quicker than the pre- 
vious one. | 


In the above example, CM. 2’s Conwinner and Conloser sessions had such widely 
different RU sizes because of mode consistency and propagation problems. 
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VTAM’s definition for CICS specified a mode table where there was no #BATCH 
entry(a propagation problem). Because there was no #BATCH entry available used 
default values to set up sessions 3 and 4. These default values(like RU size = 256 
bytes) were a lot smaller than what CM. 2 asked for(a consistency problem). 


Data Link Control(DLC) Recommendations 


- The DLC used to connect SNA protocols to physical networks will affect user 


response time. In this section, I descnbe the issues you must be aware of when 
tuning SNA to run on your Token Ring. 


DLC adapter card selection 


DLC frame size 


Recommendation 


When possible (t.e. affordable), upgrade to the highest capacity DLC adapter 


card. 


An adapter is an installable circuit board which allows your computer to attach to, 
and communicate over, data networks. It provides the physical and the logical con- 
nection between vour PC and a network transport facility (i.e. X.25 networks). 
These boards generally slip into one of your PC’s expansion slots. 


Evolution in DLC adapter cards has made their selection a performance issue. New 
hardware architectures have implemented DLC protocols that can achieve through- 
puts near the speed of the media they transmit data over. All data either send from, 
or received by, your PC must go through the adapter. Therefore, any tuning per- 
formed on an adapter will lead to more efficient use of the transport network by the 
upper layers of SNA. 


Later, in “Platform Specific Recommendations” on page 27, I include a ranking of 
different Token Ring cards based on available test data. 


Recommendation 


Send the largest possible DLC frame size allowed for a given link. This will 
require that the partner machine can receive such a large frame. If two machines 
have two different frame sizes configured, the lesser of the two sizes will be used. 


Exception 


Noisy (error prone) links. 


When configurable, increasing the packet size that a DLC uses to transmit data 
strongly increases data throughput for large data transfers. This 1s true regardless of 
the transport(e.g SDLC, Token Ring): 


¢ The more user data sent per packet, the more efficient the transport becomes 
due to the increase in the ratio of user data to control data. 
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¢ The greater the number of bytes that can be transmitted in one packet. the less 
times that the sending machine has to contend for bandwidth on the trans- 
mission medium. 


¢ A small DLC frame size can force unnecessary RU segmentation(see ‘‘Seg- 
menting RUs” on page 19). Also, depending on the SNA implementation, a 
small DLC frame size can limit the size of RUs that can be sent over a link (see 
example below). 


Example 


A link, LINK 1, is defined with a maximum frame size of 1024 bytes. For 
the link protocol, the link header and trailer total 44 bytes. All sessions 
going over LINK]! might have a limit on their RU size of 1024-44 = 980 
bytes. 


DLC pacing 


Recommendation 


Use the maximum allowable DLC pacing window your SNA product will allow. 
links. 


Exceptions 
¢ For links connecting CM{[2 to NS/[DOS, a window size of 2 is optimal. 


¢ It is only appropriate to set a large DLC pacing window for reliable trans- 
ports. Unreliable transports (those with high or widely fluctuating bit error 
rates) can penalize or negate the benefits of a large window. It is intuitive: 
an unreliable link increased the possibility of data retransmission. The more 
data that a sending machine has outstanding on a poor link, the more likely 

that large retransmissions will have to occur. 


Similar to RU pacing, DLC pacing controls the number of DLC frames a machine 
can send before stopping data transmission and waiting to receive a link level 
acknowledgement. If a small window 1s specified. data transfer may intermittently 
stop in order to wait for acknowledgement for data packets previously sent. Exces- 
sive Waiting for acknowledgements can be avoided in most cases by specifying a 
large DLC pacing window. A more effective use of bandwidth 1s thus achieved. 


DLC pacing windows on a particular machine are different depending on the direc- 
tion of data flow. So, like with RU pacing windows, remember to increase both the 
send and receive windows when tuning your SNA product. 


In most products, increasing the window size leads to better throughput. 


Trade offs 
In SNA. the DLC 1s the facility that guarantees the safe delivery of data. This 
means data which a DLC has sent. but not received an acknowledgement for, must 
be kept in memory. This stored data will only be discarded when a message 1s 
received that a copy of it has been received safely. The data receiver must also guar- 
antee that it has set aside enough memory to receive all of this data. For these 
reasons, increasing the window sizes increases the memory requirement to run SNA, 
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Efficient memory usage is most important in small machines. The memory con- 
sumed by DLC pacing windows will limit the number of sessions and links the 
SNA product can support. In order to balance better performance with efficient 
memory usage, a maximized pacing window may not always be necessary: 


¢ Ifthe remote machine is on the same physical LAN segment. acknowledge- 
ments will flow back to the sender quickly. In this environment, a small DLC 
pacing value may suffice since very few frames would ever be sent before being © 
acknowledged. 


¢ If the communicating machines are further apart, perhaps connecting over a few 
miles of bndged LANs or hundreds of miles of SDLC connections, then a larger 
window will be needed. 


In general, the larger the distance and/or the greater the number of devices that sia 
arate two machines, the larger the DLC pacing window should be. 
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Platform Specific Recommendations | 


Communications Manager/2 (CM/2) tuning recommendations 


The way users make changes to CM/2 is through the CMSETUP application. This 
can be found in the Communications Manager Folder on the OS/2 desktop. 


Users of Extended Services(ES) must use the Advanced pull down menu to make 
configuration changes. 


Increasing RU Size 
CM ‘2 has two settings for RU size, and each has its ments. 


Default RU size will set the RU size exactly large enough to fit in one DLC 
frame. When a large DLC frame 1s used. this may suffice for small data trans- 
fers. 


Maximum RU size will allow the RU size to become as large as 16,384 bytes. 
This size RU will fit in one frame for a 16 megabit per second Token Ring. 
and cause segmentation to occur for DLC’s which support less than a 16,393 
byte frame. Regardless of the maximum frame size that the underlying trans- 
port supports, increasing the RU size will increase the efficiency of bulk data 
transfer. 


Recommendation 


Use 16,384 for your RU size. 


Session pacing window value 
CMM ‘2 allows for a receive pacing window of up to 63 RUs. 


CM 2's send window will be determined, based on availability of buffers at the 
machines the data travels through, while the data transfer is in progress. See 
Appendix C, “Determining pacing window sizes” on page 63 for instructions on 
how to tell what size pacing window Communications Manager is using. 


Recommendation 


Always choose 63. 


Personal Computer(PC) LAN adapter cards 
Following 1s a listing, in order of most to least capability, of the PC LAN adapter 
architectures: 


¢ Mucrochannel cards 


1. *LAN Streamer(32 bit) adapter and *LAN Streamer(16 bit) adapter are the 
best for OS 2 desktops, servers and local bridges. 


2. IBM Token Ring Network 16/4 Adapter. A “Shorty” adapters are best for 
remote bridges for DOS desktops because of their low memory requirement. 
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3. Turbo Adapter 
4. Standard adapter 
Note: # 


Machines with Lan Streamer cards can get additional performance increases 
from upgrades to their CPUs. With LAN streamer cards, the central CPU 
perfroms most of the DLC function. 


e Fisa bus cards 


1. For OS 2 or other multitasking operating systems, the IBM 16,4 Busmaster 
EIS.A card is the best performer. 


2. For the DOS operating system and bridging devices, the IBM Token Ring 
Network ISA-16 is best. 


¢ Isa BUS(AT) cards 


1. For OS 2 or other multitasking operating systems, the IBM Token Ring 
Adapter II is the best performer. 


2. For the DOS operating system and bridging devices, the IBM Token Ring 
Network IS.A-16 1s best. 


<a Recommendation 


hen possible (i.e. affordable), upgrade to the highest capacity DLC adapter 
card. 


DLC frame size 
CM 2 allows the user to configure a DLC frame size for most of the data transports 
it Supports. 


Recommendation 


Maximize the DLC frame size. This will require that the partner machine ts also 
configured to receive such a large frame. 


DLC pacing 
Most, but not all, DLC types that CM _ 2 supports have a configurable pacing 
window. 


Recommendation 


For those DLCs which allow a configurable pacing window, maximize the window. 
[f memory shortages appear, consider lowering the size of the window to free up 
some memory (see “Trade offs” on page 24 for a discussion of memory and 
window size trade offs). 
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Networking Services/DOS (NS/DOS) tuning recommendations 


RU size | 
| RU sizes in NS; DOS are limited by the DLC frame size. Only one RU per frame 
is allowed. 


Recommendation 


Code '*’ for RU size in your NS/DOS MODE.NSD file. This will size the RU 
optimally inside of one DLC frame. 


RU pacing window size 
Recommendation 


Maximize the RU send pacing window and the RU receive pacing window. If 
memory Shortages eventually appear, consider lowering the RECEIVE pacing 


window to free some storage. Lowering the SEND RU pacing window size won't 
Save any Storage. : | 


NS: DOS doesn’t allow users to set a send RU pacing window size on a mode defi- 
nition, only a receive pacing window. The send window size will be set during 
session negotiation with the partner. This value can be found in the mode defi- 
nition, in the partner computer, for the mode you are using for your bulk data 
transfer sessions. 


With fixed pacing, memory may be wasted. Unfortunately, the level of fixed pacing 
that is appropnate will be dependent on where the destination machine 1s, and 
therefore how quickly acknowledgements can make it back to the DOS machine. 
See “Trade offs’ on page 19 for guidance on this issue. 


PC LAN adapter cards 


Recommendation 


When possible (i.e. affordable), upgrade to the highest capacity DLC adapter 


card. | 


Following is a listing, in order of most to least capability, of the PC LAN adapter 
architectures: 


e Microchannel cards 


1. *LAN Streamer(32 bit) adapter and *LAN Streamer(16 bit) adapter are the 
best for OS/2 desktops, servers and local bridges. 


2. IBM Token Ring Network 16°4 Adapter’A “Shorty” adapters are best for 
remote bndges for DOS desktops because of their low memory requirement. 


3. Turbo Adapter 
4. Standard adapter 
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Note: * 


Machines with Lan Streamer cards can get additional performance increases 
from upgrades to their CPUs. With LAN streamer cards, the central CPU 
perfroms most of the DLC function. | 


¢ Eisa bus cards 


1. For OS 2 or other multitasking operating systems, the IBM 16'4 Busmaster 
EISA card is the best performer. 


2. For the DOS operating system and bndging devices, the IB\1 Token Ring 
Network IS.A-16 1s best. 


¢ Isa BUS(AT) cards 


1. For OS:2 or other multitasking operating systems, the IBM Token Ring 
Adapter II 1s the best performer. 


2. For the DOS operating system and bndging devices, the IBM Token Ring 
Network ISA-16 is best. 


i Recommendation 


Maximize your DLC frame size. This is done via the TRA\IF statement in the 
CONFIG.NSD file. If you are using Token Ring, apply PTF# 1C06030 to enable 
NS/DOS to support a 4464 byte frame. The machine that NS/DOS is sending 
data to will then have to be configured to recerve frames this large. If memory 
shortages appear, consider lowering the size of the window to free up some 
memory (see “Trade offs” on page 24 for a discussion of memory and window 
size trade offs). 


The frame size for the DLC that data traffic is transported on should be as large as 
possible, whether it is Ethernet, Token Ring. SDLC. etc. In NS:DOS, the 
maximum RU size 1s directly affected by the DLC frame size which sessions are 
flowing over. 


For Token Ring support in NS DOS 1.0. there was a bug that was recently fixed 
which limited maximum I-frame size to 2048 bytes even if a value of 4464 bytes was 
specified. The PTF number for the fix 1s 1C06030. 


Recommendation 


If you are configuring a NS/DOS station to talk with CM/2, use 2 for the DLC 
send and receive pacing windows. Otherwise, maximize the DLC pacing window 
sizes to 8. If memory shortages appear, consider lowering the size of the window 
to free up some memory (see “Trade offs” on page 24 for a discussion of memory 
and window size trade offs). 


The MAXIN and MAXOUT parameters tell NS-DOS what values to use for 
receive and send DLC pacing. respectively. 


30 Getting the most from APPC: A network tuning guide 


APPC Market Enablement 


The MAXIN and MANXOUT parameters are specified on the TRLD statement in 
the CONFIG.NSD file. 
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SNA Services/6000 v1.2 tuning recommendations 


The parameters affecting SNA Services’6000 are set via the Svstem Management 
Interface Tool(SMIT). You can skip directly to the SNA panels by entering “smut 
sna’. 


DLC frame size 
Recommendation 


Use the SYSTEM DEFINED setting. 


The SYSTEM. DEFINED option will optimize the DLC frame size based on the 
charactenstics of the DLC transport. 


DLC pacing 


Recommendation 


Set the send and receive values to 127. 


During my tests. I discovered a problem with the Token Ring driver in SNA 
Services 6000. The dnver shipped with AIX version 3.2.4 had a problem when con- 
necting to NCP V6R2. The symptoms of the problem 1s: 


¢ When transferring data via an APPC session, and using a DLC send pacing 
window greater than 10, the link connecting SNA Services 6000 to NCP fauls. 


I applied APAR IX41022 to fix the problem. 


127 frames is the maximum window size configurable in SNA Services. 


LAN adapter queue depth 


Recommendation 
Set the send and receive queue depths to 150. 


RU size 


Recommendation 


Set the RU size to 3840, the maximum for SNA Services/6000 v1.2. 


RU pacing window size 
Recommendation 


Set the send pacing window to 127. 
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Optimal memory buffer settings 
AIX allows the user to do memory management for some AIX subsystems. SNA 1s 
one of those subsystems. 


Recommendation 


Use the following commands to increase the amount of memory SNA 
Services/6000 can use: 


© no -o thewall= 8192 
e no -o lowclust = 256 
° no -o lowmbuf= 256 


¢ no-o mb_cl_hiwat = 512 


There are four buffer threshold values the user can sect which control how much 
memory SNA Services'6000 can use to send and receive data: 


1. “mb_cl_hiwat” 


to 


The maximum number of free clusters SNA Services’6000 will allow in its pool 
of buffers before it starts returning clusters to the AIX system. Clusters are 4 
Kbytes long. 


. owclust” 


The smallest number of free clusters SNA Services 6000 will allow in its pool of 
buffers. If the number of free clusters in SNA Services/6000’ space dips below 
this value, SNA Services'6000 requests more clusters from the AIX system. 


. Jowmbuf” 


Similar to “lowclust”: the smallest number of free mbufs SNA Services6000 will 
allow. mbufs are 256 bytes long. 


. “thewall” 


Controls the maximum amount of clusters and mbufs SNA Services ’6000 can 
use. This number 1s in units of Kbytes. All of this memory can be paged. 


Increasing mb_cl_hiwat and thewall will improve performance by decreasing the 
number of tumes SNA Services/6000 must request and free memory. Increasing 
lowclust. lwombuf, and thewall will give SNA Services ‘6000 more memory to work 
with. SNA Services‘6000 can then better handle bursty and busy conditions in the 
network. 


These increases in memory consumption must be weighed against the memory 
needs other applications and subsystems on your AIX system. 
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~AS/400 tuning recommendations 


You can change the parameters of AS ‘400 communications system through the 
AS 400 control language or through system panels. The AS 400 Communications: 
Advanced Peer-to-Peer Networking Guide will help with making necessary changes. 


AS/400 performance tools 


You should use AS‘400 performance tools if available on vour system: 
¢ Performance Tools’400(5738-PT1) 


— Automatic System Tuning - available with the base operating system 
through the QPFRADJ system parameter(set to | for IBM standard set- 
tings, 2 for dynamic tuning). 

— Advisor 

— Specialized tools: Capacity planner, System Planner, Transaction report. 


¢ Performance Investigator. 400(PRPQ 5799-PRG) 


RU size 7 
For calculating RU size, OS‘400 gives the user a lot of help. The *CALC value in 
the Mode Definition(NfODD) provides optimal RU sizes. 
—_ Recommendation ee 
Always use *CALC for the RU size. | 
RU pacing 


Recommendation 


Use 7 for both IN and OUT pacing in the Node Definition(\IODD). 


LAN adapters(IOPs) 


r-— Recommendation 


When possible (i.e. affordable), upgrade to the highest capacity DLC adapter 


card. 


Different IOPs(adapters) have different performance charactenstics. Some important 
issues are: 7 


e High capability adapters have the potential to overrun lesser capable adapters. 
This has the effect of causing retransmissions and time outs on the links 
between disparate adapters. The AS 400 performance tools can help determine 
the frequency of time outs and retransmissions. If they are occurring frequently, 
configure the adapters to use LANMAXOUT = 2 and LANACKFRQ = 1. 


¢ For interactive environments, the adapter utilization should be kept under 60% 
to guarantee consistent response times. But, for bulk data transfer environ- 
ments, it is acceptable to exceed this threshold. The utilization of the adapter 
can be determined using the AS 400 performance tools. 
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¢ Many adapters can be attached to a single AS'400. It is important to distribute 
work evenly across these adapters for maximal performance. For help with 
task, see AS’400 Communications: Local Area Network Guide(SC41-0004). 


¢ The more advanced adapters(2617 and 2619) have a microcode feature which 
assists the main processor in segmenting RU data (see “Segmenting RUs” on 
page 19 for a discussion of segmentation). This reduces the load on the main 
CPU and will be of great benefit in bulk data transfer when segmentation 1s 
likely to occur. | 


The adapters are listed here in order of most to least capability: 
Token Ring adapters 
1. Model 2619 - 16/4 Mibit’sec Network adapter’ HP 
2. Model 2626 - 16/4 Mbit’sec Network adapter.A 
3. Model 2636 or Model 6130 IOP with 6134 adapter - 16 4 Mbit’sec Token Ring 
4. Model 6160 or Model 6130 IOP with 6034 adapter - 4 Mbit sec Token Ring 
Ethernet Lan adapters 
1. Model 2617 IOP Ethernet(IEEE 802.3) Adapter HP 
2. Model 2625 IOP or Model 6130 OPP with 2635 adapter - Ethernet subsystem 


DLC Frame size: MAXFRAME parameter 


OS/400 allows administrators to increase the size ai the DLC frame for all of its 
supported DLCs. The default frame sizes for these are not optimal. 


Recommendation SSS 


Maximize the DLC frame size 


¢ For Ethernet(ELAN) Token Ring() TRLAN) SDLC and ISDN, the frame 


size is changed only when MAXFRAME is changed in both the Line 
Description(LIND) and Controller Description(CTLD) 


¢ For X.25 transport, change the DFT PATSIZE in the LIND. 


DLC pacing: LANMAXOUT and LANACKFRQ parameters 


Internal IBM tests show that for most environments, the *CALC values for these 
values is optimal. *CALC sets LANACKFRQ=1 and LANMANOUT=2. For 
pure bulk data transfer environments, however, increasing these 1s appropniate. 


Recommendation 


Unless you are sure that a link is dedicated to bulk data transfer, choose *CALC 
for LANMAXOUT and LANACKFRQ. 


For links dedicated to bulk data transfer, increase them to LANACKFRO= 2 and 
LANAMAXOUT = 4 and note any change. If no improvement results from this 
change, return the values to *CALC. 
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NCP tuning recommendations 


Make changes to NCP parameters by changing NCP definition statements and Gen- 
erating a new executable NCP module. For assistance with NCP Generation use 
the NCP, SSP, and EP Generation and Loading Guide. 


RU Size: MAXBFRU and UNITSZ parameters 
Recommendation 
For each NCP, do the following: 
I. Set UNITSZ to 4000 bytes. 


2. Determine the size of the largest PIU which NCP will have to transfer. This 
will be slightly smaller than the size of the DLC frames that NCP receives 
from other machines. See “Basic concepts” on page 13 for details on PIUs. 


3. Then dwide that PIU size by the UNITSZ value, round up to the nearest 
integer. That will be the best N[AXBFRU value. 


Note: 


You may have to increase this NfAXBFRU value by I if your sessions are 
failing. In my tests, 1 sent 4000 byte frames from CM /2 to VTAM anda 
MANXBFRU = 2 was required to avoid session failures. 


4. Then, make sure that the following parameters follow this rule: 


MAXNDATA(V TAM, NCP) > UNITSZ*MAXABFRU > PIU size 


The number of buffers set aside in NCP to receive an RU 1s specified by the param- 
eter MANBFRU. Each of these buffers is UNITSZ in length. As NCP receives 
data, it fills these buffers up, waiting for all data to armve. If too many buffers are 
specified per RU, there are two adverse side effects: 


¢ Lnused buffers are wasted 


¢ NCP will wait unnecessarily. NCP waits until all of the buffers specified by the 
MAXNBEFRU parameter are full before forwarding the data. Eventually, if those 
butfers don’t fill, a tumer expires and the buffers are forwarded. This is ineffi- 
cient behavior. 


The size of these buffers. UNITSZ, also affects performance. Large internal buffers 
allow NCP to transfer bulk data more efficiently than small buffers. 


BFRS 
NCP main memory buffer sizes can be altered. BFRS defines the length of these 
buffers. 7 | 


Recommendation 


Use 240, the maximum value allowed. 
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SLODOWN 
| NCP will enter a protective mode called slow down when it is in danger of running 
out of storage. You can tell NCP different thresholds at which to enter slow down 
via the SLODOWN parameter. The number specified is a percentage; so a value 6 
says to NCP enter slow down when you only have 6% of your NCP’s memory free 
for new data. | | 


Recommendation 


Use a value of 6. This will allow NCP to conserve 6% of its buffers when 


network traffic is heaviest. 


DELAY 
The DELAY option allows you to choose a timer value which tells VTAM how 
long to hold FM data(user data) before sending it to NCP. This timer strongly 
influences the rate at which pacing acknowledgements and confirmation messages 
get back to NCP attached machines. If the DELAY value is too high, pacing 
mechanisms will be disrupted. | 


Recommendation 


Set DELAY to 0. 


NCP Token Ring Ian adapters 
Different NCP Token Ring adapters have different capabilities. They are listed here 
in best to worst order: | 


1. TIC2 - 64K bytes of storage 16 or 4 Mbits’sec 
2. TIC] - 2576 bytes of storage, 4 Mbit/sec speed only 


DLC frame size 


RCVBUFC | 
This parameter controls the size of buffers used to receive DLC frames inbound to 
NCP. | 


RCVBUFC must be large enough to receive two whole DLC frames from a periph- 
eral station. If this value is too small, NCP mav have to ask an end station to 
retransmit data. Also, connection failures may occur if an end station sends a frame 
which is too large for NCP to receive in one buffer. 


Recommendation 


Make RCV BUFC at least twice as large as MAXTSL(see below). The 
maximum values are: 

¢ 4,095 bytes for TICI adapters. 

¢ 32,000 bytes for TIC2 adapters. 
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MAXTSL 
This parameter affects the size of Token Ring DLC frames that NCP can send to, 


and receive from, penpheral Token Ring stations. 
Recommendation 


Follow these guidelines based on the adapter type in your NCP: 
¢ For TIC! adapters, never exceed 1108 bytes. 
¢ For TIC2 adapters running at 4M bits/sec, use 4060 bytes. 
¢ For TIC2 adapters running at 16M bits/sec, use 16,000 bytes. 


DLC Pacing 


T2TIMER 
The T2TIMER definition statement specifies three different values for use by the 


NCP. It appears as follows: 


T2TIMIER = (T1,T2,W) | 
¢ Tlis the acknowledgement time out value for local LAN connections 


¢ T2 is the acknowledgement time out for remote connections(connections to a 
partner on a different physical LAN segment). 


e W is the receive acknowledgement count. 


When NCP receives DLC frames, it keeps a tumer and a count active for each Link. 
Either the timer expires. or the number of frames received equals W. In either case, 
an link level acknowledgement is sent for all frames received since the NCP last sent 
an acknowledgement. W 1s also called the receive pacing window size. 


There 1s a double standard in the way that NCP treats the acknowledgement 
window (W’) specified in the T2TIMER: 


¢ For Subarea connections, the value W will be used as the acknowledgement 
window size. 


¢« For penpheral connections. NCP uses only two window sizes: | and 2. If the 
T2TIMER statement 1s specified for a penpheral connection, NCP uses a value 
of 2. If the T2TIMER operand 1s not specified, a value of one 1s used. 
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Recommendation 


¢ Use the T2TIMER operand on LINE and BUILD statements defining periph- 
eral connections to machines which support a SEND window of greater than 
I. Code T2TIMER = (1,1,2). | 


¢ If NCP is connected to a lot of peripheral stations that don't support a 
SEND window of greater than I, then either use a local timeout (TI) of less 
that 200 milliseconds( < 0.002) or don't specify T2TIMER at all. This will 
keep the end stations from waiting too long for NCP acknowledgements. 


¢ For subarea connections, use large values for the parameters specified by 
T2TIMER. Experimentation to find the proper window size is necessary 
because, as with any fixed pacing scheme, raising the window above a certain 
level offers no pay back and will waste storage. Try starting with large values 
like T2TIMER = (1,3,16). Then, note any changes in performance(not an 

easy task, I admit!) when you change to (1,3,32), (1,3,64) and (1,3,127). 


MAXOUT 
This parameter specifies the number of DLC frames NCP can send before requiring 
a DLC acknowledgement. The proper number for this parameter must be deter- 
mined by the capacity of the receiving machine. | 


Recommendation 


Set \LANOUT as large as possible based on the type of link you are setting it for 


(see below). 
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VTAM tuning recommendations 


RU size 


IOBUF 


To make changes to VTAM, you must make changes to VTAM’s definition 
members(files). Help with this task can be found in the WTAM Resource Defi- 
nition Reference. 


RU sizes are coded in a unique way in VWTAM. The actual value is specified as a 
base and mantissa in the RUSIZES statement in the MMODEENT macroinstruction. 
This macroinstruction 1s part of a mode table which VTAM uses to read mode 
information. 


The value RUSIZES = X’8787' would mean that both SLU to PLU and PLU to 
SLU RU sizes for a particular mode would be 8*2**7 or 1024 bytes. 


Recommendation. 


VTAM supports up to a 64k byte RU size. Use RUSIZES=X’8D8D' for the modes 
which your bulk data transfer applications use to transfer data. The name of this 


mode table can be found in the APPL statement for the V TAM application (see 
example below to help determine what your V TAM application is). 


r—— Example of a VITAM application 


A VTAM application is any system resource that opens an Access Control 
Block with VTAM. If your host application uses CICS for its CPIC Applica- 
tion Programming Interface (API). then CICS is vour VIAM application. 
Likewise, APPC/MYVS provides a CPIC API for host applications and could be 
your VITAM application. 


APPC; MVS was one of my VTAM applications for my tests tests. The fol- 
lowing 1s the definition I used. 


TOMVSAP APPL ACBNAME = TOMVSAP,APPC= YES... 


MODETAB= tunemode,..,V PACING = 32.... 
DLOGMOD=#INTER... 


Any changes I made to BATCH (the mode I used for bulk data transfer tests) 
were made to the mode table tunemode. More information on changing a mode 
table 1s available in Appendix D, “Replacing a mode table in VTAM” on 

page 65. 


The IOBUF operand tells VAM what size to make the buffers it uses to send and 
receive data from channel attached controllers (e.g. 3172. 3174, 3745). The larger 
the buffer size. the less processing that 1s required to receive and send large amounts 
of data. 
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Recommendation 


Set IOBUF to 4000 bytes. 
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Matching parameters across platforms for better performance 


VTAM with CICS 3.3 


SENDSIZE and RECEIVESIZE 
These parameters control the data buffer size that CICS uses when exchanging 
application data with VTAM. They can range from 1 to 30,720 bytes. CICS can 
limit RU size negotiation with the SENDSIZE and RECEIVESIZE parameters. 
These are coded in the connection definitions for end stations. 


Recommendation 


Code both SENDSIZE and RECEIVESIZE large enough to accommodate the 


RU size that end stations want to negotiate. 


Automatic session setup 
The AUTOCONNECT option on a session definition in CICS, and the AUTOSES 
option on the APPL statement in VITAM, can have a side effect that can lead to 
performance problems. 


AUTOCONNECT(ALL) and AUTOSES are functions that can be used to bind as 
many sessions as a mode’s session limit when a LU first contacts another. When 
VTAM binds all of the sessions for a particular mode, it might not have all of the 
information necessary to make the Conwinner and Conloser sessions equivalent. 
VTAM. NCP and CICS offer so many different options that might lead to the RU 
sizes in Conwinner and Conloser sessions, between a host and another machine, to 
be very different. Depending on the session selected for a conversation, bulk data 
throughput will differ. 
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Recommendation 


For CICS, make the SENDSIZE and RECEIVESIZE equal for any end station 
which will perform bulk data transfer with CICS. See “SENDSIZE and 
RECEIVESIZE” for further explanation on SENDSIZE and RECEIVESIZE. 


For end stations connecting to VTAM or NCP follow the recommendations in 
“Mode Consistency and Propagation” on page 21. 


For VTAMI|NCP, make sure the following parameters match up: 
© MAXDATA > = MAXTSL 
© RCVBUFC = 2x MAXTSL 
¢ JOBUF size(V TAM start option) = UNITSZ(NCP) = 4000 
¢ For any bulk data transfer Mode, make sure the RUSIZES on the MMODE 
definition has the same value for all RUste.g. RUSIZES =x’ ABAB’ and not 
RUSIZES =x’ ABCD’). 
When coding FTAM definitions: 


¢ Define the VIAM application( like CICS or APPC/MVS) and the PU con- 
necting to VTA M Cike NS/DOS or SNA Services/6000) with the SAME 
mode table. 
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Appendix A. Test lab results - microcomputer and mainframe 


network 


The above platform specific recommendations came from lab work performed at 
IBM. | 


Methodology 


At the time of print of this publication, only single APPC session throughput was 
investigated. Further investigations to determine the best parameters for multiple 
session throughput, and data transfer from the host to desktop machines, may be 
done in the future. 


The benchmarks 

| The details of the design of the File Transfer benchmark used for the tests can be 
found in “Classic Client-Server transactions using APPC” by Dr. John Walker and 
Lance Bader(1). | 7 


Memory to memory data transfer 
The goal of the tests conducted at IB was to determine how to tune the SNA 
communications stack most effectively. For that reason, a memory to memory 
CPIC benchmark was selected which simulates an efficient file transfer operation. 
The measurement recorded was total throughput achievable by the SNA transport. 
I O overhead and operating system calls to retrieve data were. therefore, not part of 
the data transfer measurement. The overhead required for allocating APPC conver- 
sations and, or performing non communications processing is beyond the scope of 
this tutonal. See Appendix E, “Additional performance related publications” on 
page 67 for additional performance source material. For that reason, the maximum 
throughputs reported here will not be representative of what you can achieve in a 
real data transfer environment where disk access 1s incurred. I report the maximum 
numbers and gains here to give you a frame of reference as to what is attainable in 
environments similar to my test networks. | | 


What was measured 
Conversation allocate(CMALLC) and deallocate(CMMDEAL) verbs are not included 
in the measurement times in this benchmark. Only the time required to issue all of 
the CMSENDs to send all of the data and a CMRCYV to receive a confirm at the 
end of the transfer was recorded. 


Many of these transactions were performed and an average time was derived for 
each data transfer transaction. 
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Figure 5. Nlicrocomputer Nlainframe network 


Highlights 
Before tuning was performed on the network, a baseline set of runs were made. 
The state of the VWTAM NCP Composite network node used as a server was that of 
a typical production machine with many differing user demands. Many upgrades 
and changes had been made to VTAM and NCP over time. The end station pro- 
ducts used were loaded fresh out of the shrink wrap and the shipped defaults were 
used for the baseline run. For the baseline run, the following was achieved: 


¢ Maximum throughput achieved for NS-DOS to VITAM was 

a 100,000 byte file transferred in 31 seconds = 0.0258 Mbit/sec. 
¢ Maximum throughput achieved for OS ‘2 to VTAM was 

a 1,000,000 byte file transferred in 6.4 seconds = 1.25 Mbit/sec. 
° Maximum throughput achieved for RS to VTAM was 

1,000,000 byte file transferred in 8.66 seconds = 0.924 Mbit/sec. 
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Tuning was then performed on the machines 1n the network using all known tuning 
techniques, with the following results: 


¢ Maximum throughput achieved for NS°-DOS to VTAM was 


a 100,000 byte file transferred in .53 seconds = 1.51 Mbit/sec, a 98% reduction 
_ in transfer time relative to the base run. 


Note: Paying close attention to the MANBFRU and DELAY parameters in 
NCP opened up NS/DOS’s throughput immensely. 


¢ Maximum throughput achieved for OS’2 to VTAM was 


a 1,000,000 byte file transferred in 5.1 seconds = 1.57 Mbit/sec, a 20% 
reduction in transfer time relative to the base run. 


Note: RU size and DLC pacing had the most effect on OS/2 performance 
¢ Maximum throughput achieved for RS to VTAM was 
a 1.000.000 byte file transferred in 4.74 seconds = 1.69 Mbit/sec, a 45% 


reduction in transfer time relative to the base run. 
¢ Using either CICS or APPC/MVS provided nearly equivalent results for all 


client machines. 


Details of the data transfer and hardware used 
In the tests conducted using the microcomputer and mainframe network, data 
transfer rates were measured for data sent from the small machines to the MVS 


host. 
To scale the data transfer sizes to the machines’ capabilities, two “file sizes” were | 
used for the benchmark: | 
1. 100,000 bytes for sending from NS’DOS to VTAM 
2. 1,000,000 bytes for CM ‘2 to VTAM and SNA Services. 6000 to VTAM VTAM. 


The machines used in the network were: 


IBM 4381 
© Memory requirement was less that 1 Megabyte so storage size was not a factor 
* MVS 4.2.2 | 
¢ APPC.MYS provided with MVS operating system 
= CICS 3.30 
¢ VIAM 4.1 


IBM 3745-410 
¢ § Megabytes RAM 
¢ Type6 3 Megabyte block channel adapter 
¢ TIC2 Token Ring adapter set for 4 Mbit ‘sec 


RS/6000 Power station 530 
¢ SNA Services ‘6000 v1.2 
© AIX 3.2.4 
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32 Megabytes main storage 


PS/2 Model 80 


Communications manager'2 1.0 

Intel 80386 20 Megahertz processor 

12 Megabytes of memory 

IBM 16°4 Mb Token Ring Adapter, A set for 4 Mbit. sec 
OS 2 2.1 


32 bit Microchannel bus 


PS/2 Model 60 


Networking Services; DOS 1.0 

DOS 6.0 

Intel 80286 10 Megahertz processor 

IBM 16.4 Mb Token Ring Adapter set for 4 Mbit ‘sec 
7 Megabytes of memory | 


16 bit Microchannel bus 
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Base and tuned parameters 
The following charts detail the changes I made to achieve the performance improve- 
ments listed above. In each chart, the ?>CODED column describes where each 
_ parameter is coded(configured) in the software products used. 


Base parameters: When I made the baseline performance muns, no tuning was 
done. Here’s how the machines looked to start off. | 


Figure 6 (Page 1 of 2). Baseline parameter settings. 


2?CODED 


Value 
CICS 
SENDSIZE Session definition 
RECEIVESIZE 4096 bytes Session definition 
- VTAM 
RUSIZES x’FTF7’ 


PACING ae default | LU statement for end 
= station(e.g. DOS) 
VPACING | 0 PU statement for end | 
. station(e.g. DOS) 3 
Mode 3 MODEENT statement 
PSNDPAC | 
Mode | 3 ~MODEENT statement 
SSNDPAC ; 
| Mode. 3 MODEENT statement 
SRCVPAC | 


IOBUF (200.384,,, 100,50) VTAM start list 
| NCP 
MAXDATA 65535 PCCU statement 


Channel VR PATH statement for 
pacing VTAM: NCP Channel 


[petay ate“ =PECU teen 


UNITSZ 384 HOST statement 
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Figure 6 (Page 2 of 2). Baseline parameter settings. 
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DLC RECEIVE 


PACING 


:- 


RS/6000 


Lan adapter 30 SMIT tok() profile 
Transmit Q size | 
Lan adapter 30 SMUT tok() profile 
Receive Q size 
DLC Transmit 10 | SMIT DLC logical link | 
Count | , profile 
DLC Receive boy SMIT DLC logical link 
Count profile 


DLC Window SYSTEM DEFINED SMIT DLC logical link 
Size : profile 


owiehe er 


Mode Send 3 SMIT Mode profile 
Pacing 
3 Mode Receive 3 SMIV Mode profile 
Pacing 
RU SIZE * (960 negotiated) MODE.NSD file 
RU Receive 3 MODE.NSD file 
Pacing | 
DLC FRAME 987 CONFIG.NSD file 
SIZE 
DLC MAXIN 2 TRLD statement - 
CONFIG.NSD file 
DLC MAXOLT | 2 TRLD statement - 
CONFIG.NSD file | 
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Tuned parameters 


VTANI 


RUSIZES | x 8D8D' | MODEENT statement 
PACING . default LU statement for end 
station(e.g. DOS) 
i: PACING PU statement for end 
station(e.g. DOS) 
Mode MODEENT statement 
PSNDPAC 
Mode MODEENT statement 
SSNDPAC 
Mode. MODEENT statement 
SRCVPAC 


IOBUF (200,4000,., 100,50) | VTAM | VTAM start list | | VTAM start list | 


NCP 


65535 - PCCU statement 
MAXDATA | — 
Channel WR (255,255) Channel PATH statement 
pacing 


pear [eet 

[pres [OO —*dC« tet 

-Stopows | SiC tet 

Ciseres [OST sttement 

ES EE —— Ae 
OS2 


PACING Receive pacing = 63 CMSETUP Modes panel 
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Figure 7 (Page 2 of 4). Tuned network parameter settings. 
pant CODED 
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Figure 7 (Page 3 of 4). Tuned network parameter settings. 


| DLC TRLD statement - 
MAXNOUT CONFIG.NSD file 
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Appendix B. “APPC Optimal Performance Configuration on 
OS/2 and DOS” | 


This document describes the APPC parameters that can be changed from the 
default values to optimize APPC performance on OS'2 and DOS. These findings 
are the results of performance testing conducted by APPC Market Enablement 3 in 
Research Tnangle Park, North Carolina. 


The goal of the tests was to use standard transactions to determine optimal perform- 
ance of APPC. The configuration was tuned independently for cach transaction to 


provide the maximum number of transactions per second. 


The results indicate that protocol performance is dependent on the size of the trans- 
action records as well as the type of adapter being used. 


This document presents the test methodology and the results of the performance 
tests. 


Test Environment 


Microcomputer test network 


PS/2 Model 95 PS/2 Model 95 
80486 33Mhz 80486 33Mhz 
16 Mbyte RAM 16 Mbyte RAM 


Figure 8. Nlicrocomputer network 
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Maximum throughput 


CM/2 server CM/2 client Turbo adapter card: 8.89 Mbit/sec 


CM/2 server CM/2 client Busmaster adapter card: 10.91 Mbit/Sec 


NS/DOS server CM/2 client Turbo adapter card: 5.63 Mbit/Sec 


CM/2 server NS/DOS client Turbo adapter card: 3.86 Nbit/Sec 


Both the OS 2 and DOS tests were run on two 80486 33 megahertz (MHz) IBM 
Model 95s. Each machine had 16 megabytes (MB) of memory and was configured 
for 64 kilobytes (KB) of shared RAM on the token-ring card. The two machines 
were connected with a dedicated 16 megabit (Mb) token-nng. 


For the OS 2 tests, two token-nng cards were configured on each machine. IBM 
16.4 Adapter A Turbo token-ring adapters and IBM Busmaster adapters were used. 
All performance measurements were obtained with the machines communicating 
with the same type of adapter. Separate measurements were obtained for communi- 
cations using the Turbo cards and using the Busmaster cards. 


For the DOS tests, only the Turbo adapters were used. 


The OS 2 platforms were running OS’2 2.0 with Extended Services 1.0 without any 
available corrective services delivenes (CSDs). Extended Services provides the 
APPC protocol stack for OS;2. The OS/2 machines were configured as LEN 
Nodes for the APPC tests. 


The DOS platforms were running DOS 5.0 with Networking Services‘ DOS, which 
provides APPC support. 


The transactions simulated for these tests were a 100,000-byte file transfer trans- 
action and a 100 byte inquiry transaction. These are the two transactions that were 
selected by the SAA performance council for comparisons. 


File Transfer Transaction 


For the file transfer transaction the client sends 100,000 bytes to the server using 
32.000-byte application-level buffers. The client receives one acknowledgement 
from the server when the transaction completes, indicating the data has arrived suc- 
cessfully. The measurements obtained were based on the average of 1.000 repe- 
titions of this transaction. 
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Inquiry Transaction 


Benchmarks 


os/2 


DOS 


The client sends 100 bytes to the server and the server returns 100 bytes to the 
client. 100-byte application level buffers were used. The measurements obtained 
were based on the average of 20,000 repetitions of this transaction. 


The following APPC benchmarks replicate the file transfer and inquiry transactions. 
To provide a true measure of the API transaction time, the benchmarks do not 
perform any disk access or memory copies. 


The Bader Benchmarks, which are generally accepted for APPC client-server 
benchmarking, were used to obtain the APPC performance measurements. 


The OS 2 benchmarks used the APPC API with basic long-running conversations. 
The conversation is maintained after the transaction ends and can be re-used for the 
next repetition of the transaction. Long-running conversations eliminate the over- 
head of conversation set-up in the performance measurements. 


To minimize the factors that affected performance on the OS/2 machines, the 
benchmarks were run in OS;? full-screen mode without any other processes running 
in the background. 


Both the client and the server were OS/2 machines. 


Networking Services DOS provides the Common Programming Interface for Com- 
munications (CPI-C) in place of the APPC programming interface. Consequently, 
the CPI-C versions of the benchmarks were used for the DOS tests. 


Networking Services/DOS cannot link directly with another DOS platform running 
Networking Services'DOS. The DOS performance benchmarks were run with the 
DOS machine communicating with an OS;2 machine for these tests. Measurements 
were obtained both with the OS.2 machine performing the server duties while com- 
municating with a DOS client and with the OS? machine acting as a client with a 
DOS server. 


Configuration for Optimal Performance 


In order to tune the protocols for optimal performance, some default values of the 
configuration parameters were altered. 


When large amounts of data are being transferred. APPC provides the best perform- 
ance when most parameters in the configuration are set to their maximum value. 
These settings increase the size of the packets that are sent across the link and utilize 
the adaptive pacing provided by APPC. 


The DLC RU size was the factor that most significantly umpacted performance with 
large data transfers for both OS:2 and DOS. However, for OS 2, this 1s one param- 
eter that should not be maximized. OS’2 APPC performance for the file transfer 

transaction improved as the RU was increased up to a point. The value chosen for 
the final performance measurements on OS 2 was a value in the middle of the range 
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providing maximum performance. For DOS, this value should be maximized for 
optimal file transfer performance. 


Although there were a few parameters that could be tuned to improve performance 
for the inquiry transaction, performance was generally not affected by vanations of 
the parameter settings. Increasing the mode receive pacing window resulted in shght 
performance improvements on both the OS.2 and DOS platforms but all other 
parameters provided equal performance as had been provided using the default 
values. The inquiry transaction performed well when the parameters were increased 
to match the optimal performance configuration for the file transfer transaction. 
Optimizing APPC configuration for large data transfers also optimizes performance 
for smaller data transfers. 


For APPC on DOS, the DLC send and receive window count was an important 
factor in performance tuning. Networking Services: DOS performs better when this 
value 1s decreased to 2 from the default value of 4. 


Definition of Parameters 
Following are descnptions of the parameters that were changed from the default 
values to provide optimal performance for each transaction. 


Adapter Card Buffer Size 
Size of the buffers on the network adapter card. It 1s applicable to busmaster 
adapters only and 1s defined in the OS 2 Busmaster .NIF file. 


Adapter Driver Recewe Buffer Size 
Size of each receive buffer. It 1s applicable to busmaster adapters only and ts 
defined in the OS, 2 Busmaster .NIF file. 


DLC Frame Size 
Physical frame size used by the LAN adapter for communications from your 
workstation. This parameter is defined in the Networking Services. DOS 
CONFIG.NSD file. 


DLC Send/Receive Window Count 
Number of frames that the station can send before receiving an acknowledge- 
ment or receive before sending an acknowledgment. It 1s defined in the OS/2 
APPC .CFG file 


Max DLC RU 
Maximum request. response units supported by this adapter and defined 1n the 
OS’2 APPC .CFG file. 


Mode Receive Pacing Window 
Protects the nodes on a session from flooding that can occur when one node 
sends data faster than the other node can receive and process it. This param- 
eter 1s defined in the OS. 2 APPC .NDF file. 


Session Receive Pacing Window 
Used to determine the amount of storage required in the RU buffer pool. 
Pacing windows are negotiated between your workstation and the partner LU 
when the session 1s activated. This parameter is defined in the Networking 
Services DOS MODE.NSD file. 
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Parameter Settings 
Following are the values used for specific configuration paramcters. 


Notes: 


° The first platform listed indicates the client. For example, OS;2-DOS indicates 
an OS:2 client communicating with a DOS server. 


¢ Parameters that did not affect configuration are not listed in the following 
tables. | 


¢ Table entries containing default values indicate the default value provided per- 
formance that 1s better than or equal to all other settings. 


¢ Table entry ’--’ indicates the parameter is not applicable in the test configura- 
tion. 


¢ Total Improvement is a percentage improvement from the time obtained when 
the benchmarks were run with the default settings. 


Table 1 - Tuned Values for APPC Parameters on OS/2 


This chart indicates the values of configuration parameters that provide the best per- 
formance on an OS 2 machine. Each parameter is named in the first column with 
the default value for this parameter which is set at installation specified in the 
second column. 


The following four columns (3-6) indicate the values to which these parameters 
should be set for optimal performance on an OS:2 machine when communicating | 
with another OS:2 machine. In some cases, the parameter values vary depending on 
the adapter being used and or the type of transaction being run. This chart breaks 
the number down accordingly to indicate these vanances. 


The last four columns (7-10) indicate the values to which these parameters should 
be set for optimal performance on an OS/2 machine when communicating with a 
DOS machine running Networking Services/DOS. In some cases, the values for 
these parameters vary depending on the type of transaction being run and whether 
the OS ‘2 machine 1s acting as a client or as a server. Columns seven (7) and eight 
(8) indicate the values for the parameters if the OS/2 machine 1s the client. 
Columns nine (9) and ten (10) indicate the values for the parameters if the OS/2 
machine 1s the server. This chart breaks the number down accordingly to indicate 
these variances. 


Appendix B. “APPC Optimal Performance Configuration on OS 2 and Dos” 59 


APPC Nlarket Enablement 


Figure 9. Tuned Values for APPC Parameters on OS 2 
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Receive 256 2048 2048 2040 256 2040 256 
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Table 2 - Tuned Values for APPC Parameters on DOS 
This chart indicates the values of configuration parameters that provide the best per- 
formance on a DOS machine running Networking Services‘'DOS when communi- 
cating with an OS 2 machine running Extended Services. 


Each parameter 1s named in the first column with the default value for this param- 
eter which is set at installation specified in the second column. The following four 
columns (3-6) indicate the values to which these parameters should be set for 
optimal performance on a DOS machine running Networking Services’ DOS when 
communicating with an OS 2 machine running Extended Services. In some cases, 
the values for these parameters vary depending on the type of transaction being run 
and whether the OS 2 machine 1s acting as a client or as a server. Columns three © 
(3) and four (4) indicate the values for the parameters if the DOS machine 1s the 
server. Columns five (5) and six (6) indicate the values for the parameters if the 
DOS machine is the client. This chart breaks the number down accordingly to indi- 
cate these vanances. 
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Figure 10. Tuned Values for APPC Parameters on DOS 
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OS/2 


Following are the results of the OS‘2 performance tests after tuning the configura- 
tion for optimal performance. 


Figure 1]. OS 2 APPC Performance Results (Inquiry) 


Adapter Card Seconds/Transaction Transactions/Second Effective Throughput — 


Figure 12. OS 2 APPC Performance Results (File Transfer) 


Adapter Card Seconds/Transaction Transactions/Second Effective Throughput 
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DOS 


Following are the results of the DOS performance tests after tuning the configura- 
tion for optimal performance. 


Figure 13. DOS APPC Performance Results (Inquiry) 


| ee Seconds/Transaction Transactions/Second Effective Throughput 
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Figure 14. DOS APPC Performance Results (File Transfer) 


Seconds/Transaction Transactions/Second Effective Throughput 


DOS Chent .2070 secs 4.83 3.86 Mb 


Conclusion 


APPC’s performance improves significantly when the default parameters are tuned 
for the file transfer transaction. Since. this configuration also provides optumal per- 
formance for the inquiry transaction, those seeking optimal performance should tune 
APPC configuration as specified in the previous charts. 


62 Getting the most from APPC: A network tuning guide 


APPC Market Enablement 


Appendix C. Determining pacing window sizes 


¢ SNA Services’6000 


The pacing calues used for a session can be found in the MODE profile that the 
session is using. You can access this mode profile by using SMIT. 


« CM’'2 


To know what size pacing send window CM ‘2 1s using, a data transfer in 
progress must be traced. I recommend two ways of accomplishing this: 


1. Use the APPNPACE utility available from APPC Market Enablement 
APPNPACE should be available in mid March, 1994. 


2. You can check what size the window is opening up to by using 
APPNT(start APPN Trace), APPNF(Format APPN trace). 


a. Issue “APPNT” in an OS/2 command prompt. 

b. Run your data transfer. 

c. Issue “APPNF filenarne(no extension!)” in an OS:2 command prompt. 
Note: 


CM2 creates three files at this time: fi/lename.SUM, filename.DET, and 
filename. TRC 


d. Edit filename.SUM, and search for “IPM” 


The number appearing in the brackets of IPM(#) is the window the 
receiving machine 1s allowing CM/2 to send. 


To check CM, 2’s receive pacing window, you must look at a mode definition 
configuration panel. If you were using the mode BATCH, for example, to 
transfer data over and you wanted to see the receive pacing window for 
BATCH: 


1. For CM:2 use the CMSETUP application to look at mode definitions. 


2. For Extended Services. follow this series of menus: 
ADV ANCED- > CONFIGURATION- > SNA FEATURE 
PROFILES- > SNA FEATURE CONFIGURATION- > OTHER SNA 
FEATURES. 
e NS DOS 
Use the “NSD LIST ,SE” command. Among the data displayed wul be the 
send and receive pacing window for each section. 
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Appendix D. Replacing a mode table in VITAM 


A mode table must be compued and reloaded into VTAM before any changes made 
to it take effect. 


Compiling 
— See the VTAM Network Implementation Guide, IBM publication SC32-6419, for 
detauls. 


Reloading 
| Use the MODIFY TABLES command to replace the current mode table with the 
new(most recently compiled) version. I used 
MODIFY NET, 
TABLES,.OLD = TUNEMODE, NEW = TUNEMIODE.OPTION = LOAD 


Where NET was the MVS procedure name(proc) that VTAM was started with. 
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Appendix E. Additional performance related publications 


1. “Performance Considerations in an APPC. MVS Environment” - IBM publica- 
tion GG66-3206. | 


2. ’VTAM™ Performance Benchmark Study Results Version 4 Release | for 
MVS:ESA” - IBM Publication GC31-6415. IBM publication GG66-3206. 


3. The AS ‘400 Communications: Advanced Peer-to-Peer Networking Guide IBM 
Publication $C31-8188. 


4. NCP, SSP, and EP Generation and Loading Guide - IBM Publication 
SC30-3348 


5. VTAM Resource Definition Reference - IB1 Publication SC31-6427. 
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